Methods, systems, and computer program products for managing access resources in an internet protocol network

ABSTRACT

Exemplary embodiments relate to managing access resources in a network. Methods include receiving a request for network service, the request including a required class of service; accessing a storage device that specifies routers and bandwidth available on the routers; selecting a router from the specified routers and a port on the selected router to perform the requested service, the selecting including verifying that the bandwidth available on the selected router and port can perform the requested service, where the bandwidth is divided into a plurality of capacity classes and the bandwidth in each class can perform the requested service if the capacity class corresponds to the required class of service; transmitting instructions to a network configuration system to initiate activation of the requested service on the selected router and port; and updating the storage device to reflect the requested service being activated on the selected router and port.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/317,055 filed Dec. 22, 2005, the contents of which are incorporatedherein by reference in their entirety.

BACKGROUND

Exemplary embodiments relate generally to Internet protocol (IP)networks, and more particularly, to methods, systems and computerprogram products for managing access resources in an IP network.

IP networks with quality of service (QoS) have the capability ofhandling traffic in a differentiated manner so that the serviceproviders (SPs) can offer different levels of QoS. This means that thecustomer user is assured by the SP that from each access site, the usercan send information packets at specified rates with certain burstingcharacteristics and delivery qualities relating to latency, jitter,packet loss, etc.

One of the problems for the SP is to be able to clearly define theservices to be offered with their QoS characteristics and present themin service order (SO) language defining the services, packages and soon. This language must then be translated into the parameters and valuesthat can drive the logic and controls of an operation support system(OSS) provisioning system. The OSS provisioning system must be aware ofthe resources the SP has available to provide these services, and beable to account for these resources as customers grow, change or deletetheir services. All of this data must be constantly updated to thenetwork that supports the service and provides the resources beingmanaged.

As a customer transmits packets of data (containing for e.g., data,voice, and video information) into the network, each router must knowexactly how to police the incoming traffic, how to place packets intoQoS queues, how to handle packets that are “out of contract” (i.e.,above contractually assured traffic limits), how to route the packets,and how to assure that there is no cross-talk between users (i.e., thatno users can listen in on data being transmitted for another customer.

Currently, managing the resources that provide access to an IP networkwith QoS is largely a time consuming and manual process. It would bedesirable to be able to provide an automated method for allocatingresources to a customer service in an IP network with QoS. In addition,it would be desirable to manage these resources throughout the life ofthe service as it changes over time.

SUMMARY

An exemplary embodiment is a computer implemented method for managingaccess resources in a network. The method includes: receiving at acomputer system a request for network service, the request including arequired class of service; accessing at the computer system a storagedevice that specifies routers and bandwidth available on the routers;selecting at the computer system a router from the specified routers anda port on the selected router to perform the requested service, theselecting including verifying that the bandwidth available on theselected router and port can perform the requested service, where thebandwidth is divided into a plurality of capacity classes and thebandwidth in each class can perform the requested service if thecapacity class corresponds to the required class of service;transmitting at the computer system instructions to a networkconfiguration system to initiate activation of the requested service onthe selected router and port, the instructions specifying a quality ofservice corresponding to the required class of service; and updating atthe computer system the storage device to reflect the requested servicebeing activated on the selected router and port.

An additional exemplary embodiment is a system for managing accessresources in a network. The system includes an input device, aprocessor, and an output device. The input device is for receiving arequest for network service, the request including a required class ofservice. The processor is in communication with the input device andincludes computer instructions for facilitating: accessing a storagedevice that specifies routers and bandwidth available on the routers;selecting a router from the specified routers and a port on the selectedrouter to perform the requested service, where the selecting includesverifying that the bandwidth available on the selected router and portcan perform the requested service, wherein the bandwidth is divided intoa plurality of capacity classes and the bandwidth in each class canperform the requested service if the capacity class corresponds to therequired class of service; and updating the storage device to reflectthe requested service being activated on the selected router and port.The output device is in communication with the processor and is fortransmitting instructions to a network configuration system to initiateactivation of the requested service on the selected router and port, theinstructions specifying a quality of service corresponding to therequired class of service.

A further exemplary embodiment is a computer program product formanaging access resources in a network. The computer program productincludes a tangible storage medium readable by a processing circuit andstoring instructions for execution by the processing circuit forfacilitating a method. The method includes: receiving a request fornetwork service, the request including a required class of service;accessing a storage device that specifies routers and bandwidthavailable on the routers; selecting a router from the specified routersand a port on the selected router to perform the requested service, theselecting includes verifying that the bandwidth available on theselected router and port can perform the requested service, where thebandwidth is divided into a plurality of capacity classes and thebandwidth in each class can perform the requested service if thecapacity class corresponds to the class of service; transmittinginstructions to a network configuration system to initiate activation ofthe requested service on the selected router and port, the instructionsspecifying a quality of service corresponding to the required class ofservice; and updating at the computer system the storage device toreflect the requested service being activated on the selected router andport.

Other systems, methods, and/or computer program products according toexemplary embodiments will be or become apparent to one with skill inthe art upon review of the following drawings and detailed description.It is intended that all such additional systems, methods, and/orcomputer program products be included within this description, be withinthe scope of the present invention, and be protected by the accompanyingclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings wherein like elements are numbered alikein the several FIGURES:

FIG. 1 is a block diagram of an exemplary network environment withaccess resources that may be managed according to exemplary embodiments;

FIG. 2 is an overview of a system and process for managing accessresources in an Internet Protocol (IP) network in accordance withexemplary embodiments;

FIG. 3 is a block diagram of a system that may be utilized to manageaccess resources in an IP network in exemplary embodiments;

FIG. 4 is an exemplary embodiment of a process flow that may be utilizedto manage access resources in an IP network; and

FIG. 5 is a block diagram of an exemplary network environment thatincludes a service provider managed facility that has access routersthat may be managed by exemplary embodiments.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Exemplary embodiments include a method for managing access routerresources in an Internet protocol (IP) network with quality of service(QoS). The resources managed include variable resources that varydepending on the number and types of equipment (e.g., bandwidth “BW”)and fixed resources that are fixed by the type of equipment. Examples offixed resources include, but are not limited to: the number of virtualprivate networks (VPNs), routing and forwarding (VRF) tables, routetargets (RTs), routings distinguishers (RDs), policy maps, policers,access queues, IP security (IPSec) sessions, and point to point protocol(PPP) sessions a given router can provide.

Exemplary embodiments provide a very flexible, parameter-driven processfor defining the accounting for resources as assignments in the networkare designed to provide a customer with an IP-based service (e.g. directInternet access (DIA) and IP/VPN access). Resources are allocated to thecustomer's service and managed throughout the life of the services as itchanges over time and eventually is deleted from the network.

FIG. 1 is a block diagram of an exemplary network environment thatincludes access resources that may be managed according to exemplaryembodiments. The network environment includes two networks: a serviceprovider network 102 and the Internet 104. In addition, FIG. 1 depictsseveral sites being connected (in a variety of manners) to the serviceprovider network 102 or to the Internet 104. The example connectionsinclude, but are not limited to, a private line connection, anasynchronous transfer mode (ATM) connection, a frame relay connection,two digital subscriber line (DSL) connections, two IPSec connections,and a cable connection. In addition, the service provider network 102and the Internet 104 are connected with each other, with a firewall onthe service provider network 102 side of the connection. Using a networkenvironment such as the one depicted in FIG. 1, an authorized user fromany of the sites will be able to transfer data and/or voice to any ofthe other sites. In exemplary embodiments the service provider is atelephone company with a service provider network 102 that has beenbuilt on broadband technology. This broadband technology is utilized asa base to provide the newer voice services to customers.

FIG. 2 is an overview of a system and process for managing accessresources in an IP network that may be implemented by an operationalsupport system (OSS) in accordance with exemplary embodiments. A serviceorder (SO) (including a class of service (COS)) is received from acustomer. Next, a work order (WO) is created from the service order andentered into the OSS by a customer service representative 302 (shown inFIG. 3). In alternate exemplary embodiments the WO is receivedelectronically and/or directly from the customer requesting the service.Exemplary embodiments provide a mapping of the language of the WO to thecapacity accounting mechanisms used to define, tally, allocate andmanage the network's resources. The mechanism maintains awareness of theamount of available resources, the resources required to fulfill a givenservice request, the reservation of these resources, and the maintenanceand reporting of the resources. Exemplary embodiments also facilitatethe end of process of initiating, changing and deleting services whichentails the mapping from the capacity mechanisms to the commands andcodes communicated with the network routers so they are configuredproperly to provide the given services.

The COS language in the WO is mapped to the capacity classes and thelogic of the services to be provided. The services are designed andresources allocated and accounted for. Then, the network is configuredwith the designated resources to provide the service at the QoSpurchased.

Exemplary embodiments assume that a mechanism such as a computer system(e.g., an OSS) is capable of maintaining an inventory of the equipmentutilized in IP networks, has the logic to design IP services using thisinventory, is programmed to provide the processing described herein, canbe programmed to map COS language to the mechanisms of the method, andcan communicate configurations to an IP network.

IP packets are transmitted across an IP network making use of a field inthe header of the packet called the type of service (TOS) bits. Thesebits allow for values from 0 to 7 and routers examine these bits todetermine the priority, queues, and methods for handling the packets.Based on these eight possible values, exemplary embodiments provide forusers of the OSS to define up to eight capacity classes. In exemplaryembodiments, the users can specify, for each class: the name of theclass; a percentage of the BW of a managed entity that will be allocatedto this class; a subscription factor that will allow over subscriptionor enforce under subscription of the class; and major and minorthresholds that will cause alerts to be issued when these thresholdshave been crossed.

Exemplary embodiments also provide for the pre-allocation of the BW(i.e., prior to the above allocation to the classes) to remove part ofan entity's BW capacity from consideration, taking into account one ormore of the following: overhead factors since the payload of a port orrouter is always lower than its theoretical speed; a redundancy factorto set aside resources to cover failure cases; and an unmanaged servicesfactor since the OSS may not manage off of the services that are funacross the network it manages.

Exemplary embodiments assume that resources will be managed at theprovider edge routers (PEs) in service provider (SP) data centers andtherefore the above mechanism will be implemented for these routers,certain ports on these routers, the data center as a whole and otherlogical entities designated for special services. This allows the OSS tomake assignments related to WOs based on the amount of traffic thatcustomer is buying for this service. This customer's traffic is thentallied with all other customers and the totals are managed such that nocustomer can usurp the resources planned for other customers and thenetwork as a whole can be managed to avoid hot spots, congestions,interference of some customers by others and so on. The OSS will providetemplates for all the types of equipment used in the PEs of the SP(e.g., router, card, port types) and these templates designate theamount of BW and the numbers of fixed resources this type of equipmentwill provide. The users define the topology of their network in the OSSinventory for their areas of services. As equipment is defined, theresources designated in the templates are tallied and allocated into theBW capacity mechanism above and into the counters for fixed resources atthe appropriate levels. These then are the “money in the bank” that canbe used to provide services to end user of the network services anddebited from the available resource counts as each service is designedby the OSS.

With the OSS set up, the topology of the network defined and resourcesallocated into resource counters and capacity classes, the OSS userdefines the service to be provided to the OSS, mapping the wordsdefining the service and COS of the service to the capacity classes andlogic of the system design logic. For example, if the end customer wantsan IP connection from this point to that point with a speed of 10megabits/second and a COS level of “gold” in this direction and 20megabits/second in the other direction with a COS level of “silver”, allbased on frame relay technology. The frame relay PVCs and the IPconnections across the network can be configured such that the 10Megabits of gold traffic are scheduled into faster queues with higherreliability than the 20 Megabits of silver that are scheduled into a mixof lower speed queues. This would be desirable if, for example, thetraffic the customer expects has more voice or video in the golddirection and more data or email in the other.

FIG. 3 is a block diagram of a system that may be utilized to manageaccess resources in an IP network in exemplary embodiments. The systemincludes one or more user devices 302 through which requestors (e.g., acustomer service representative) at one or more geographic locations maycontact the host system 304 to access the OSS described herein. Inexemplary embodiments, the host system 304 includes a processor toexecute the OSS to perform the functions described herein. The OSS maybe implemented by software and/or hardware components. The OSS system isin communication with a network configuration system 310 for making theactual changes to the network configuration based on instructions fromthe OSS. In exemplary embodiments, the user devices 302 are coupled tothe host system 304 via a network 306. Each user device 302 may beimplemented using a general-purpose computer executing a computerprogram for carrying out the processes described herein. The userdevices 302 may be personal computers, lap top computers, personaldigital assistants, cellular telephones, host attached terminals, etc.with user interfaces for communicating with the OSS. The user interfacesmay be implemented by interface screens, audio technology, voicerecognition technology, or any other technology to allow the user tocommunicate with the OSS. If the user devices 302 are personal computers(or include the required functionality), the processing described hereinmay be shared by a user device 302 and the host system 304 (e.g., byproviding an applet to the user device 302) or contained completelywithin one or more of the user devices 302.

The network 306 may be any type of known network including, but notlimited to, a wide area network (WAN), a local area network (LAN), aglobal network (e.g. Internet), a virtual private network (VPN), and anintranet. The network 306 may be implemented using a wireless network orany kind of physical network implementation. A user device 302 may becoupled to the host system 304 through multiple networks (e.g., intranetand Internet) so that not all user devices 302 are coupled to the hostsystem 304 through the same network. One or more of the user devices 302and the host system 304 may be connected to the network 306 in awireless fashion.

The storage device 308 may be implemented using a variety of devices forstoring electronic information. It is understood that the storage device308 may be implemented using memory contained in the host system 304 orthe user device 302 or it may be a separate physical device. The storagedevice 308 is logically addressable as a consolidated data source acrossa distributed environment that includes a network 306. Informationstored in the storage device 308 may be retrieved and manipulated viathe host system 304. The storage device 308 includes OSS data such asthe access routers and the resources available on these routers. Thestorage device 308 may also include other kinds of data such as systemlogs and user access profiles. In exemplary embodiments, the host system304 operates as a database server and coordinates access to applicationdata including data stored on storage device 308.

The host system 304 depicted in FIG. 1 may be implemented using one ormore servers operating in response to a computer program stored in astorage medium accessible by the server. The host system includes aninput device for receiving The host system 304 may operate as a networkserver (e.g., a web server) to communicate with the user device 302. Thehost system 304 handles sending and receiving information to and fromthe user device 302 and can perform associated tasks. In addition, thehost system 304 also communicates with the network resources to causethe requested service to be added to the network. The host system 304may also include a firewall to prevent unauthorized access to the hostsystem 304 and enforce any limitations on authorized access. Forinstance, an administrator may have access to the entire system and haveauthority to modify portions of the system. A firewall may beimplemented using conventional hardware and/or software.

The host system 304 may also operate as an application server. The hostsystem 304 executes one or more computer programs (e.g., via a processoron the host system 304) to implement the OSS. Processing may be sharedby the user device 302 and the host system 304 by providing anapplication (e.g., java applet) to the user device 302. Alternatively,the user device 302 may include a stand-alone software application forperforming a portion or all of the processing described herein. Aspreviously described, it is understood that separate servers may beutilized to implement the network server functions and the applicationserver functions. Alternatively, the network server, the firewall, andthe application server may be implemented by a single server executingcomputer programs to perform the requisite functions. The input devicein the host system 304 may be implemented by a receiver for receivingdata (e.g., a request) over the network 306 or via the user device 302.The output device in the host system 304 may be implemented by atransmitter for transmitting data (instructions) over the network 306 orto the user device 302. Alternatively, the input device and/or outputdevice may be implemented by reading from and writing to a storagelocation on the host system 304 and/or the storage device 308.

FIG. 4 is an exemplary embodiment of a process flow that may be utilizedto manage access resources in an IP network. In exemplary embodiments,the process flow is implemented by the OSS described herein. At block402, a request for IP network service is received by the OSS. Therequest for service includes a required class of service (COS). Asdescribed previously, the WO language in the request for service istranslated into capacity/QoS language for use processing by the OSS. Atblock 404, the system (i.e., OSS) accesses the storage device 308 thatspecifies routers and resources available on the routers for the IPnetwork. At block 406, the system selects a router to perform therequested service. Part of the selecting verifies that the selectedrouter has the resources to perform the requested service. Examples ofhow the router is selected are described below herein. At block 408, thesystem causes the requested service to be activated on the selectedrouter. This may be performed by transmitting a command to a networkconfiguration system 310. At block 410, the storage device is updated toreflect that the requested service has been activated on the selectedrouter.

FIG. 5 is a block diagram of an exemplary network environment thatincludes a service provider managed facility including access routers.FIG. 5 includes a service provider managed facility 502 (SPMF) thatincludes several routers for moving voice and data from one location toanother. An SPMF is commonly known in modern telecommunications as adata center. It is the data communications equivalent of the older voiceworld central office. The various router names in the picture (LNS, BER,ISR, IRR, CER, HER) are not important per se but represent a variety orrouters of different size and providing different functions or services.Customers may enter the SPMF 502 via the scenario depicted in block 504.This includes a local area network (LAN) in communication with acustomer edge router (CE) which is in communication with a FR or ATMnetwork. The FR or ATM network is in communication with three provideredge routers in the SPMF 502. According to exemplary embodiments, eachof these connections is subdivided into eight smaller pipes that receivedifferent priorities of service. Alternatively, a customer may accessthe SPMF 502 via the scenario depicted in block 506. Block 506 includesa customer connected via a remote PC or a CE into a DSLAM which isconnected to the SPMF 502 via a BBG. According to exemplary embodiments,block 506 represents a Digital Subscriber Line (DSL) connection in whichan ATM network carries the customer's data between the customer'sequipment and a central broadband gateway (BBG) where the ATM traffic ofmany customer's is bundled together in a high capacity IP connection fortransport to the IP carrier's network. The core of a service provider'sIP network is the set of very high capacity, long-haul IP connectionsthat provide the IP highways between geographically dispersed SPMFs.This is called the ‘backbone’, depicted in FIG. 5 as the ServiceProvider Routed IP Backbone (SPRIB). The SPRIB 508 is utilized to allowthe customer to talk to someone in another city via another SPMF. TheIE2100 in block 512 allows the SP to communicate with the customer's CEto update and manage this equipment for the customer. In addition, thecustomer (e.g., from box 504 and from box 506) may talk or transfer datavia the Internet 510.

The subsequent paragraphs provide more details about exemplaryembodiments that may be implemented and/or facilitated by the OSS (alsoreferred to as the “system”). Where existing applications to performrequired functions are available, the OSS may invoke them to perform allor part of the functions described herein. Where existing applicationsto perform required functions are not available the computer code toperform the functions is located in the OSS.

In exemplary embodiments, provisioning for DIA and IP VPN includes:

-   A. Receipt, verification and analysis of WOs.-   B. Design and assign (D&A) of the services requested in the WOs. D&A    will include capacity and resource availability management and other    rules based logic for best management of PEs and the access trunks    to PEs.-   C. Assignment of inventory objects with object creation,    modification and deletion as required, capacity and resource    commitments to the database, management of all associations and    relations between inventoried objects, and status management of all    objects.-   D. WOs to be provisioned include new orders, disconnect orders and    “move, add and change” (MAC) orders for DIA and IP VPN services. For    dedicated access, methods such as, but not limited to, frame relay    (FR), ATM and private lines are available. For non-dedicated access,    methods such as, but not limited to, IPsec, DSL site-to-site and    remote access are available. Various combinations of access to the    network are possible with the lowest access having the SP provide    only the port as access to the SP's network. In other cases the SP    provides the access port and the circuits from this port out to the    customer's site. The full package is for the SP to provide the    access port, the access circuit and the customer's CE (the router at    the Customer's locations, i.e., the Customer Premise Equipment or    CE.-   E. Provisioning for inward orders will assemble (not committed to    database yet) the physical, logical, and service inventory objects    for the connection from the customer to the FR or ATM cloud or the    customer end of the private line, and IPsec and DSL site-to-site and    remote access. Provisioning calls the D&A processes (performed    and/or facilitated by the OSS in exemplary embodiments) to design    accesses considering the service request, access type, access speed,    BW requirements, COS, and available resources. For dedicated access,    the best connection from the FR/ATM cloud or PL into the service    provider managed facility (SPMF) to a PE is chosen. For    non-dedicated access, the best service module (SM) to serve this DSL    or IPsec access is chosen. (Service Modules may provide other    services in the future). Note that the term “best” is defined in    later requirements but generally refers to the connection on a    preferred type of equipment, respecting user defined priorities and    fulfilling resource requirements.-   G. Set up/remove Firewall connections.-   H. Set up/remove Management PE/CE connections for managed sites of a    VPN.-   I. For DIA service, assure appropriate IP addresses (from the    customer or from the service provider for the local area network    (LAN) and from the service provider for the wide area network (WAN)    and generate packet filters and static routes.-   J. For VPN service, select/create/modify appropriate VRFs, RTs, RD,    static routes, WAN, LAN, Loop Back, IPsec and DSL Remote pool IP    addresses and subnets.-   K. Create new objects as required: customer location(s), IP pools    and customer circuits.-   L. Assure data sets for activations and other uses such as    communications with other Systems (e.g., Radius, CAFE, SOEG, WFM,    and so on).-   M. New and modified objects are handed back to the provisioning    processes that invoked this D&A.-   N. Provisioning receives the results of the D&A process and reacts    to the success or fail of the D&A process. If the D&A process is    successful, provisioning commits all objects to the database and    signals this success with appropriate information to the WO or    calling process. If the D&A process failed, provisioning will not    commit changes to the database, will see to rollback if any is    required, and will message the calling process and others as    appropriate. Provisioning for outward orders consists of clean up of    deleted and/or cancelled objects. Provisioning for outward orders is    not invoked for the de-activation of the service but only for the    de-allocation of the service as a manual or scheduled event some    configurable time after the deactivation. Everything is left intact    for time with the service turned off via deactivation of the service    in the network. When the configurable amount of time has elapsed,    either by schedule or manual invocation, D&A recalculates the    resource counters to be changed through release of the resources    assigned to this service and gives the results back to provisioning.-   O. Provisioning receives the results of the D&A calculations.    Provisioning then commits the revised counters to the database;    deletes all inventory objects that do not persist outside of    services; releases inventory objects that do persist beyond being in    service; and restores resources to available. Provisioning for both    inward and outward orders produces the configuration information    that is handed (e.g., transmitted) to an activation module for    causing the indicated updates to the network elements (NEs). This    also includes updates to the customer's customer edge router (CE)    when that is typically managed by the service provider as part of    the service. MAC orders are moves, adds and changes to existing    services. These same actions against current WOs are called    correction passes.

A multi-protocol label switching (MPLS) VPN is based on an InternetEngineering Task Force (IETF) specification, Request For Comments (RFC)2547bis. In this RFC, the basic MPLS protocol has been enhanced tosupport VPN mechanisms. These mechanisms include VPN routing andforwarding (VRF) table, route target (RT) and route distinguisher (RD).VRFs, RDs, and RTs are supported in PE routers, not in other networkrouters or CE routers.

VRF table. There can be one or more VRFs (also comparable to a virtualrouter) per VPN that constitute a VPN. A VRF contains the set of routesthat are available to a set of sites that are part of the VPN. If allsites in the VPN participate in only that VRF and no other VRF, all PEswill contain routes such that all sites are able to reach all othersites in the VPN. This topology is called a ‘full mesh’ topology.However, a VPN can have multiple VRFs defined such that each site mightbe limited in the set of other sites it can send messages to or receivemessages from. This requires creation of multiple VRFs for the VPN,configuring them on the PEs supporting the VPN, and associating themappropriately with the sub-interfaces of those PEs. A sub-interfaceinterfaces with a customer site interface. If two or more VPNs have acommon physical site, separate sub-interfaces must be created and IPaddress space must be unique amongst these VPNs. For phase 1B, theSystem will support full mesh VRFs such that there is only one VRF perVPN.

RT. Each VPN has import route targets and export route targets (RT).These are different than IP routes/prefixes, however, are closelyrelated to IP routes. The import RT associated with a VRF dictates whichroutes the VRF should import upon arrival of Multi-Protocol internalBorder Gateway Protocol (MP-iBGP) route updates. Each IP VPN route thatis injected into MP-iBGP is associated with one or more export RTsindicating which VPNs the route belongs to. The value of this attributedepends on the VPN topology. For a full meshed (MP-iBGP between all PEs)topology, there will be one export and one import RT both with the samenumber/identification. Other topologies may need multiple different RTsassociated with a VRF. For this release, the System supports onlyfull-meshed topology.

RD. The RD makes any customer IP prefix that needs to be shared betweenthe PE VRFs, part of the same VPN, unique from other VPNs across theMPLS backbone. The RD is unique per VPN. The System supports RDs with ascope at the PE level, such that for a given customer VPN, each VRF in aPE that participates in that VPN will have a unique RD. The System shallmaintain Type 1 RDs.

Resource Management.

This following paragraphs define the methods used by the OSS to definecontrol parameters in exemplary embodiments to provide a flexible mannerof defining the resources and the logic for dealing with these resourcesthat provisioning assigns and manages to D&A services for customers.This will include QoS, BW, VRFs, RTs, RDs, PE service Profiles, PEsessions for IPsec and DSL remote service, and so on. BW and QoS areconsidered to be variable resources since they vary in amount dependingon the number and size of ports in a PE. The others listed here areconsidered fixed resources since a PE of a given type usually haslimited numbers of these resources irrespective of the amount of the PEthat is equipped.

The term “configurable” as used herein means that the object defined asconfigurable is easily changed by the service provider, at no addedcharge by the vendor, and is usually GUI-supported. There will be cases,though, were the change could have such impact that the service providerwill choose to re-align documentation and to do suitable testing for thechange before implementation of the change. These of course would besubject to charges according to the effort required by the vendor.

Exemplary embodiments will manage BW during provisioning actions ineight capacity classes. The number of these classes is determined by thethree TOS bits in IP packets (and 3 EXP bits in MPLS packets) that allowthe network to differentiate the type and priority of packets. The QoSqueues are the actual queues that the service provider sets up in its IPnetwork for handling packets of different QoS characteristics indifferent manners to deliver the QoS the customer has purchased. Therewill be a very configurable method for mapping capacity classes to QoSQueues.

As used herein, the term COS (Class of Service) is distinguished fromQoS (Quality of Service). COS is a WO term that defines what is thelevel of service that is to be provided for a given site. QoS is aprovisioning and network term that specifies how the System will mapthis site's packets to queues in the network that will provide therequested level of service.

QoS and BW capacity. QoS and BW capacity will be managed duringprovisioning as follows. Access ports other than FR and ATM ports haveno capacity accounting at the port level. They are of course checked forcompatibility with the needs of the service requested. PEs, aggregatedports and service modules have BW capacity enforced by capacity class.SPMFs have BW capacity reported by capacity class but not enforced. Notethat for BW capacity for DIA will be managed in the BW capacitymechanism as one of the services/products that the service provideroffers on this IP network.

Defining the mechanism for BW capacity management. BW capacity will beallocated into capacity classes that are defined configurably as global,default parameters that can generally receive local overrides forexceptional cases. BW assignments will be controlled by these parameterdefinitions according to the requirements describe herein and accessports will be configured to police ingressing traffic to respect thesesame definitions. The following are the general features of the overallmechanism used for these purposes. The number of capacity classes isconfigurable but is not likely to change any time soon. The usable BWcapacity of an entity will be determined by the physical or allocated BWcapacity of that entity minus a configurable percentage for overhead andminus a configurable percentage for redundancy. Note that with regard tooverhead, most routers do not count headers when managing traffic.Because of this, the real ‘payload’ of packets in a 100 Mg port cannever really be 100 Mg. This difference is called ‘overhead’ and variesdepending on the average size of packets in a given technology.

Configurable parameters are provided to specify an overhead factor peraccess type—PL, FR, ATM, IPSec site-to-site, IPsec remote, DSLsite-to-site, DSL remote and the general redundancy factor. Eachcapacity class will be allocated a configurable percentage of the BWcapacity of the entity being managed ranging from 0 to 100% of theusable BW capacity of that entity. For each capacity class, there willbe configurable parameters to define including, but not limited to: asubscription factor (over or under subscription); a minor alertthreshold; and a major alert threshold.

This set of defining and control parameters along with the impliedcounters is an exemplary embodiment of a mechanism that will govern BWcapacity management in the system. As mentioned above, these parametersare defined once for the entire system as the global defaults across theSP IP network. However there is also the possibility of definingoverrides of any of these global parameters for any given PE, SM or forany port that is managed with this mechanism. Note that subscriptionfactors will change the system's view of the BW it has to deal with. Ifa given class can be oversubscribed to say 400% and the usable BW inthat class for a given entity is 10 Mg, the system will consider thatthe entity has 40 Mg of BW. In all accounting and reporting, it will bethe 40 Mg that is available or assigned, and will reported as such.

Using the BW capacity mechanism. During D&A, provisioning will usedecision tables to determine the best PE, card and port to service agiven request. When a port is selected to this level, the system willverify that the selected port has the BW capacity in each of theimpacted capacity classes (if it is managed to that level or as a totalBW if not managed to the capacity class level) and that the PE as awhole has the available capacity in its summary view of these queues. Ifthe assignment does not involve a port but rather a service module (SM),the system checks for available capacity in the impacted queues of thatservice module. If the capacity is not available at these levels, thedesign process moves on in search of equipment that does have therequired capacity. If an assignment is made but a minor or major alertthreshold is crossed in doing so, the appropriate alerts and messagesare issued. These thresholds will be checked at the port, PE, SM and BMFlevels with each assignment. Reports are available at all these levelsthat will indicate the current state of fill and availability of BW astotals and as specific to each capacity class.

Capacity audits are specified that check the consistency of the systeminventory of assigned services with the corresponding counters at alllevels in the system to report on any discrepancies and to correct themaccording user's directions. These capacity audits will also makerequired adjustments to counters when parameters are changed that wouldcause the system to alter its view of this data. For example, a bad loadof software might have caused the counters to be out of sync with theexisting assignments. Or the service provider might have changed themapping of a certain product to capacity classes. The audits could beuse as a migration mechanism to change the allocations across thedatabase. Of course there would be a further problem of effecting thesechanges in the network, but that is a different consideration.Projecting the balance between user access and network capacity.

All PE ports that are in use (allocation status) will be designated as:access (customer facing); trunk (core network facing); and unmanaged (inuse for services not managed by the System). This designation will bepart of inventory management of infrastructure, provisioning and theinventory audits. Available ports will be considered as Access ports bydefault unless designated otherwise. The system will attempt to reporton the balance of BW capacity of access from customers and trunks to thecore for each PE and for the sum of all PEs in a BMF but will not do anyenforcement of this during provisioning.

The total current access BW for a given PE is calculated as the sum ofthe following: assigned BW in ports used for private line, ATM, and FR(capacity class for this BW is known from COS mapping); the BW of portsin use that are designated as unmanaged (capacity class for this BW isdesignated as unknown specifically and therefore is assumed to be‘shaped’ in the same proportion as the global queue BW definitions); theBW of all ports (for this PE) allocated to service modules (whether infull use of not) (capacity class for this BW is allocated according tothe ratios of the current queue counts for these service modules); andthe percentage of total trunk BW that is indicated as IPsec or DSLaccess by parameters set for this PE in inventory (capacity class forthis BW is allocated according to the ratios of the current queue countsfor the service modules that include this PE). The total current trunkBW for a PE is calculated as the sum of the BW of all ports in use astrunk ports minus: the percentage of total trunk BW that is indicated asIPsec or DSL access by parameters set for this PE in inventory and thepercentage of the total trunk BW used for unmanaged services. Thispercentage is calculated as the amount of unmanaged access divided bythe total managed access BW in use on the PE. BW is allocated accordingto the capacity class definitions for this PE described below herein.Unless overridden locally for this PE, these queue size definitions arethe general default definitions that are system-wide.

Based on these calculations, the system will able to give a roughestimate of the access versus trunk BW capacity for each of the PEs inthe network as total BW and as BW broken down by capacity class. All PEsin a SPMF can be summed up to the SPMF level so that the actual accessBW can be compared to the actual trunk BW. Furthermore the actual trunkBW allocation by capacity class can be compared to the desired capacityclass allocations. These will be the same if there are no overridesdefined for any PE in a given BMF. Note that the “usable BW” (uBW) of anentity is defined as the BW of that entity after the redundancy,unmanaged and overhead factors have been removed:uBW=[BW*(100−Redundancy)*(100−Overhead)*(100−Unmanaged)].

Fixed Resources. Fixed resources are those that are determined or fixedby the type of equipment that provides the resource such as number ofVRFs, RTs, RDs, IPsec sessions, PPP sessions, and access queues (AQs).If a PE, card, port, or service module has any limit on the number ofthese resources it can support, this will be defined either as part ofthe template for that equipment if it has such a template or asdefinition parameters when the entity is defined in the inventory. If nolimit is specified at a given level, it inherits the limit from the nextlevel up for that equipment. For example, each PE type has a limitednumber of VRFs it can handle. It is further possible that a given cardtype and its ports have their own limits beyond this. Say a given PE oftype x can handle 1000 VRFs, a given card might only handle 100 VRFs andeach port might be limited to 3 VRFs. If the port in this case had nospecific limit, it would not be tracked and only the 100 VRFs for thecard would be tracked. These limits are specified in this Inventorychapter of these requirements as part of the specifications of theseobjects. The configurable specification of these resources and theirmanagement logic is specified below in these requirements. An example ofconfigurable parameters would be the minor and major alert thresholdsfor VRFs in general.

In general, management of fixed resources is a straightforward problemof counting them as they are assigned to and released from services. Aslight wrinkle comes in considering service modules (SMs). When SMs aredefined, the user will specify a parameter that allocates a percentageof the fixed resources of each PE represented in that SM to the SM.These resources are deducted from the counts of the PE and considered inuse as far as the PE is concerned. They become available resources forthe SM and are accounted for there on a per PE basis. This is thedownside of SMs. Since the SMs select PEs on a per session basis, allPEs must have the capability to handle any session. They therefore musthave the configurations to handle any service assigned to the SM andthis requires redundant use of these fixed resources, i.e., they have tobe allocated redundantly to every PE in the SM. Note that if any portsfrom a PE are designated specifically as part of a SM and have specificlimits on any fixed resources, these limits will be ignored by thesystem since it is the province of the SM to select these ports realtime.

Resource Management Requirements BW Capacity

Note that network queues are not the same as access queues (AQ) treatedwith the fixed Resources subsequently herein. Network queues areaggregated queues in the network core—trunk ports and trunks—and carrypackets across the network. Access queues exist in dedicated accessports, police ingress packets and generally are allocated to a singleVPN access at time. This latter condition can be overridden in the caseof some best effort services.

Capacity Classes and Network Queues. In exemplary embodiments, thesystem shall provide a configurable number of capacity classes (NbCCs,default=8) and a configurable number of network queues (NbQs, default=4)that shall not exceed the number of capacity classes. Each class shallbe configurably associated with exactly one queue. The numbers ofclasses and queues shall not be overridden locally. Note that the term“BW” unqualified by any modifiers and “theoretical BW” mean the base,physical bandwidth of an entity prior to any consideration of overhead,redundancy, and so on.

BW Capacity Accounting. The system shall keep an accounting of BWassignments by capacity class (CC) for all: aggregated ports (e.g., FR,ATM); PEs; service modules (global for the SM as a whole, and local foreach BMF in which it appears); and SPMFs. Lack of available BW inrequested classes at the port, PE or SM levels shall cause theassignment to fail for that entity. Lack of BW at the SPMF level shallnot cause assignments to fail. Port BW shall be determined by line speedunless restricted by committed information rate (CIR), purchased partialspeed or other limitation. Port BW is counted as core trunk BW ifassigned as a trunk, counted assigned access BW if assigned to adedicated access or an SM, and available access BW if not assigned orpartially assigned (aggregation or limited by CIR, for example).

PE BW shall be determined by the ports assigned for use or available foruse. PE Core Trunk BW shall be the sum of the BW of all trunk ports. PEavailable access BW shall be the sum of all available port BW. PE accessBW shall be the sum of port BW assigned for access service. Allocationof Trunk BW and Available BW shall be determined by the Capacity Classparameters (defined below) that apply to this PE. Further PEconsiderations follow. Each PE could have ports (trunk and/or access)that are designated as “unmanaged.” The BW of these ports is removedfrom consideration in any other categories. Each PE shall have an“unmanaged access parameter” and an “unmanaged trunk parameter.” Theseparameters, expressed as percentages, will remove from consideration thespecified proportion of the Trunk and Access BW of the PE's totals inthese categories. For any service module defined on a PE, a percentageof the trunk BW may be allocated to that SM. In this case the systemshall consider this BW as trunk or access according to the trunk/accessratio factor for that SM, assigned in the PE's resource reports and theaccess portion as assignable for the SM.

Trunk BW shall be the line speed of ports designated as trunk ports. Seethe definition of the non-dedicated trunk to access ratio parameterbelow. Service module BW shall be determined from the BW of supportingPEs as defined as a percentage of that PE's total trunk BW or from BW ofspecific ports defined as supporting this SM. Of the BW allocated to theSM as a percentage of a PE's trunk BW total, part shall be consideredaccess available for assignment and part shall be considered trunk BW.The ratio of these parts to each other shall be configurably defined bythe trunk/access ratio factor for that SM (defaulted to 50/50). All BWfrom specific ports in the SM is considered assignable access BW. SM BWshall be accounted for each SPMF where it is present and as a total ofall these SPMFs presences. Only the total BW accounting shall controlassignments. The per SPMF accounting shall be used for reporting andaccess versus trunk BW balance analysis. Note that since the BW of an SMcan be based on the trunk BW of PEs, the theoretical BW of SMs shall berecalculated whenever the trunk BW of a supporting PE is changed.

Trunk BW allocated from a PE to an SM shall be considered “assigned”trunk BW for that PE in reports. Port BW allocated to an SM isconsidered “Assigned” BW for that PE. BW shall not be consideredallocated to an SM until the equipment supporting the SM has beensuccessfully configured for that SM (and any pre-existing servicesalready serviced by that SM).

SPMF BW shall be determined from the PEs and SMs present in that SPMF.SPMF BW accounting shall not control assignments. The per SPMFaccounting shall be used for reporting and access versus trunk BWbalance analysis.

Resource Redundancy for Service Modules. The system shall assureredundancy of resources in SMs by making sure that if any PE in a SMfails, the sum of available resources allocated to this SM in other PEsis greater than or equal to the resources allocated to the SM from thefailed PE. An example formula follows: 1. assume the failover/redundancyprinciple is that any PE can fail and the other PEs in the SM can pickup the load from that PE; and 2. assume that an SM can have any numberof PEs and any number of session contributions. If SumOthers=sum of allsessions of all PEs except the largest, and SessLargest=the sessions ofthe largest PE/contributor, then let the SessDiff=SumOthers−SessLargestand therefore, the SumOthers−SessLargest>=0, or assumption 1 isviolated, and MaxSess=SessDiff+SessLargest. The MaxSess is the number ofallocatable sessions the SM has for servicing VPN Remote services whileassuring failover redundancy. This same principle will work for each ofthe resources allocated to an SM.

BW Capacity Class Control Parameters. The system shall provide aconfigurable parameter to define an overhead factor for each accessmethod—FR, ATM, PL, IPsec and DSL Remote and Site-to-Site, and a genericoverhead factor. The system shall use the generic overhead factor incalculations unless another overhead factor is known to apply in aspecific case. For SMs whose type is determined by the access method itsupports, the overhead factor shall be the average of the overheadfactors of the access methods it supports. For any port that is assignedand supports a system-known set of access methods, its overhead factorshall be the average of the overhead factors of the access methods itsupports. Since overhead factors can be overridden locally, some localoverhead factor will apply in specific cases. In all requirements thatfollow, the term “Overhead factor” shall be understood to mean thefinally determined overhead percentage resulting from the considerationsand calculations of this present requirement. The system shall alsoprovide a redundancy factor and an unmanaged services factor. When thesystem is calculating the “usable BW” of an entity, these percentages ofthe physical BW shall be removed from consideration before the BW ofthat entity is allocated to the capacity classes as available forassignment. The usable BW (entity)=theoretical BW(entity)*[100−(overhead factor+redundancy factor+unmanaged svcs factor)]where the 3 factors shall not exceed 100.

Capacity Class (CC) Control Parameters. The system shall provide aconfigurable number of capacity classes (NbCCs, default=8) and aconfigurable number of network queues (NbQs, default=4) that shall notexceed the number of capacity classes. Each class shall be configurablyassociated with exactly one queue.

Each CC shall have an allocation parameter (CCnVol %) between 0 and 100%that shall determine the amount of usable BW of an entity is allocatedto this CC. The sum of these parameters shall always equal 100. Each CCshall have a subscription parameter (CCnSubsc %) between 0 and 1000%that shall determine the amount of assignable BW that CC has based onits allocated BW. For this parameter, 100% is full-subscription. Lessthan 100% is an under-subscription constraint and over 100% is allowableover-subscription. When this parameter is not 100%, the system shallconsider that total BW capacity of any entity in question is now raisedor lowered as indicated. (i.e., assignable BW may be different from thephysical BW.) Each CC shall have a major and a minor threshold alertparameter that the System shall use for notifications that an entity isapproaching BW exhaustion.

Each CC shall also have an access queue allocation parameter(CCnAQAlloc) that can have a value from −1 to 2 that shall determine theallocation rate of access queues (AQs) in that class. For thisparameter, the value: −1 shall indicate that the AQ count is kept butnot controlled (no limit); 0 shall indicate there is no AQ accountingdefined for this class; 1 shall indicate there is 1 to 1, assured AQaccounting defined for this class; and 2 shall indicate there isnon-assured AQ accounting defined for this class.

Capacity Class Queue Parameters. The system shall provide aGUI-configurable queue marking (CCnMarking) parameter that shalldetermine the mapping of TOS value (0-7 currently) that the networkshall use to determine the queue mapping and policing for packetsascribed to this CC. The system shall provide a GUI-configurable out ofcontract behavior (CCnOOCBehavior) parameter that shall determine thebehavior that the network shall use for packets ascribed to this CC thatexceed policed values for an assigned queue (e.g., drop, forward, remarkand forward). In exemplary embodiments, these parameters shall not havelocal overrides.

Trunk BW—Trunk to Access Ratio. For non-dedicated services (e.g., DSLand IPSec) access to the IP Network is provided by trunks rather accesscircuits for customers. In order to make projections of the balance inthe traffic across PEs as divided into the PE's customer access versusthe PE's IP network access, this non-dedicated service must be takeninto account. The system provides a non-dedicatedTrunktoAccessRatioparameter that specifies the amount of trunk BW that is considered trunkBW (i.e., BW between a PE and the IP core network) versus access (i.e.,BW between a PE and a customer). Since this only applied to trunks thatconnect PEs to the core network, this parameter shall be defaulted to50% and this shall mean that 50% of the trunk BW of a PE or SM isconsidered trunk BW and the rest is considered access BW. This parametershall have local override capability at the PE and SM levels.

Capacity Control Parameters and Factors. All these parameters andfactors shall be GUI-configurable. All these parameters and factorsshall be defined once at a system wide, general default level, and shallapply in all cases throughout the system unless there is a locallydefined override. Some service providers may require that these general,default parameters and factors be implemented as defaults, not astemplates. This means that they will not be embedded in local recordsand any changes made to them will apply immediately throughout thesystem. No migration of data is required to implement them, althoughcapacity audits may be required to true up accounting data to any newdefinitions.

The system supports GUI-supported, exceptional, configurable, localoverrides for these parameters and factors unless otherwise specified.These local overrides are permitted for any port, PE or SM for which thesystem does BW accounting. When such a local override is defined, thesystem shall apply this local override instead of the correspondinggeneral default parameter/factor. Local overrides are not affected bychanges made to the corresponding general system defaults. When a localoverride is deleted from an entity, the corresponding general defaultparameter resumes its normal function for that entity. Local overridesand subscriptions factors are taken into account for any higher levelentity affected by the setting or changing of these parameters such thatin PE accounting, the available and assigned totals for the PE equalsthe sum of all access port accounting, not counting SM allocations,having taken into account all parameter settings including localoverrides and subscription factors. In similar fashion, BMF accountingmust always represent the sum of all access PEs in that SPMF. CapacityAudits will also assure these rules.

Example: Port BW Calculation. Suppose there is a 100 Mg. port with nolocal overrides and the general default settings are: overhead=3%;redundancy=25%; and unmanaged=0%. The usable BW of this port would be:100 Mg*[100−(3+25+0)]=72 Mg. Suppose that CC3 is low latency gold without of contract (OOC) behavior forward and CC3Vol=20%. Suppose also thatCC4 is low latency silver with OOC behavior re-mark/forward andCC4Vol=20%; and that CC5 is CBW with OOC behavior re-mark/forward andCC5Vol=30%. In addition, subscription rates are 100% for CC3 and CC4,and 150% for CC5. The assignable BW of this port in CC3 would be equalto 72 Mg*20%*100%, or 14.4 Mg. For CC4 the assignable BW would be equalto 72 Mg*20%*100%=14.4 Mg. In CC5 the assignable BW would be 72 Mg*30% *150%=32.4 Mg.

Example: SM BW Calculation. Suppose an IPsec SM is defined and isallocated 25% of the trunk BW of PEx and 20% of the trunk BW of PEy. Ifthe total trunk BW of PEx=7 Gig and PEy=10 Gig, with local overrides forCCnVol all set to 0 except CC9=100, and the General Default settingsare: IpsecOverhead=2.5%; redundancy=25%; and unmanaged=0%. Thetheoretical BW of this SM would be: 7 Gig*25%+10 Gig*20%=3.75 Gig. Theusable BW of this SM would be: 3.75 Gig*[100−(2.5+25+0)]=2,719 Mg. SinceBW from PE trunk allocations is split into both trunk and access (assume50/50), the access BW for this SM would be half of this or 1359 Mg. Allof this would allocated to CC9 and if the subscription rate for this CCis 400%, there would be 5,438 Mg of assignable BW in this SM.

D&A BW Capacity Management. D&A shall manage BW capacity by calculatingthe impact on each capacity class for a given provisioning action. Thisentails using the effective BW and distributing it into class categoriesas defined by the capacity class control parameters. This specifies theamount of BW to be incremented or decremented in each capacity class forthe object being affected. If the BW allocation is decreased in anycapacity class, D&A calculates the new BW availability in that class forthis entity and all higher entities. If the BW allocation is increasedin any capacity class, D&A calculates availability of the BW in thatclass for this entity and all higher entities. If the BW is notavailable at the port, PE or SM global level, D&A shall fail thisoperation. If the BW is available at the port, PE and SM global level asapplicable, the system sets up the counters to reserve the changed BW atall levels affected by the change. These counters shall be committed tothe database by the calling routine. If the BW is available but crossesa minor or major alert threshold at any level, D&A shall generate theappropriate messaging and notifications. In the case where assignment ofa service to a port uses part of the BW of that port and causes the restof the BW for that port to become unusable (e.g., fractional service),the unusable portion of this BW is subtracted from or added back to theavailable counts for all related objects. The system shall returncontrol to the calling routine.

Exemplary embodiments provide a flexible, parameter-driven process fordefining the accounting for resources as assignment in a network aredesigned to provide a customer with an IP-based service. Resources areallocated to the customer's service and managed throughout the life ofthe service as it changes over time.

As described above, embodiments may be in the form ofcomputer-implemented processes and apparatuses for practicing thoseprocesses. In exemplary embodiments, the invention is embodied incomputer program code executed by one or more network elements.Embodiments include computer program code containing instructionsembodied in tangible media, such as floppy diskettes, CD-ROMs, harddrives, or any other computer-readable storage medium, wherein, when thecomputer program code is loaded into and executed by a computer, thecomputer becomes an apparatus for practicing the invention. Embodimentsinclude computer program code, for example, whether stored in a storagemedium, loaded into and/or executed by a computer, or transmitted oversome transmission medium, such as over electrical wiring or cabling,through fiber optics, or via electromagnetic radiation, wherein, whenthe computer program code is loaded into and executed by a computer, thecomputer becomes an apparatus for practicing the invention. Whenimplemented on a general-purpose microprocessor, the computer programcode segments configure the microprocessor to create specific logiccircuits.

While the invention has been described with reference to exemplaryembodiments, it will be understood by those skilled in the art thatvarious changes may be made and equivalents may be substituted forelements thereof without departing from the scope of the invention. Inaddition, many modifications may be made to adapt a particular situationor material to the teachings of the invention without departing from theessential scope thereof. Therefore, it is intended that the inventionnot be limited to the particular embodiments disclosed for carrying outthis invention, but that the invention will include all embodimentsfalling within the scope of the claims.

1. A computer implemented method for managing access resources in anetwork, the method comprising: receiving at a computer system a requestfor network service, the request including a required class of service;accessing at the computer system a storage device that specifies routersand bandwidth available on the routers; selecting at the computer systema router from the specified routers and a port on the selected router toperform the requested service, the selecting including verifying thatthe bandwidth available on the selected router and port can perform therequested service, wherein the bandwidth is divided into a plurality ofcapacity classes and the bandwidth in each class can perform therequested service if the capacity class corresponds to the requiredclass of service; transmitting at the computer system instructions to anetwork configuration system to initiate activation of the requestedservice on the selected router and port, the instructions specifying aquality of service corresponding to the required class of service; andupdating at the computer system the storage device to reflect therequested service being activated on the selected router and port. 2.The method of claim 1, wherein the bandwidth is divided into less thannine capacity classes.
 3. The method of claim 1, wherein the requiredclass of service is entered into an operational support system (OSS) bya customer service representative.
 4. The method of claim 1, furthercomprising: for each of the capacity classes, specifying configurablebandwidth utilization thresholds, and transmitting an alarm when thebandwidth utilization thresholds have been reached.
 5. The method ofclaim 1, wherein the selecting further includes verifying that one ormore fixed resources can perform the requested service.
 6. The method ofclaim 1, wherein the requested network service is an Internet protocol(IP) network service.
 7. The method of claim 1, wherein the router is aprovider edge router.
 8. The method of claim 1, wherein the requestednetwork service is a data service.
 9. The method of claim 1, wherein therequest for network service is for one or more of adding a new service,modifying an existing service and removing an existing service.
 10. Themethod of claim 1, further comprising receiving a notification when therequested service has been activated on the selected router and port,wherein the updating is performed in response to receiving thenotification.
 11. The method of claim 1, wherein the requested serviceis at least one of direct Internet access and Internet protocol virtualprivate network.
 12. The method of claim 1, wherein the requestedservice is for dedicated access.
 13. The method of claim 1, wherein therequested service is for non-dedicated access.
 14. A system for managingaccess resources in a network, the system comprising: an input devicefor receiving a request for network service, the request including arequired class of service; a processor in communication with the inputdevice including computer instructions for facilitating: accessing astorage device that specifies routers and bandwidth available on therouters; selecting a router from the specified routers and a port on theselected router to perform the requested service, wherein the selectingincludes verifying that the bandwidth available on the selected routerand port can perform the requested service, wherein the bandwidth isdivided into a plurality of capacity classes and the bandwidth in eachclass can perform the requested service if the capacity classcorresponds to the required class of service; and updating the storagedevice to reflect the requested service being activated on the selectedrouter and port; and an output device in communication with theprocessor for transmitting instructions to a network configurationsystem to initiate activation of the requested service on the selectedrouter and port, the instructions specifying a quality of servicecorresponding to the required class of service.
 15. The system of claim14, wherein the bandwidth is divided into less than nine capacityclasses.
 16. The system of claim 14, wherein the router is a provideredge router.
 17. The system of claim 14, wherein the requested serviceis at least one of direct Internet access and Internet protocol virtualprivate network.
 18. The system of claim 14, wherein the requestedservice is for dedicated access.
 19. The system of claim 14, wherein therequested service is for non-dedicated access.
 20. A computer programproduct for managing access resources in a network, the computer programproduct comprising: a tangible storage medium readable by a processingcircuit and storing instructions for execution by the processing circuitfor facilitating a method comprising: receiving a request for networkservice, the request including a required class of service; accessing astorage device that specifies routers and bandwidth available on therouters; selecting a router from the specified routers and a port on theselected router to perform the requested service, the selecting includesverifying that the bandwidth available on the selected router and portcan perform the requested service, wherein the bandwidth is divided intoa plurality of capacity classes and the bandwidth in each class canperform the requested service if the capacity class corresponds to theclass of service; transmitting instructions to a network configurationsystem to initiate activation of the requested service on the selectedrouter and port, the instructions specifying a quality of servicecorresponding to the required class of service; and updating at thecomputer system the storage device to reflect the requested servicebeing activated on the selected router and port.